I think it might be better to keep these parametrised memory order implementation methods private without changing the Java API by changing @IntrinsicCandidate to @ForceInline on all the [get/put/compareAnd​[Set/⁠Exchange]]​<Type>​[/Opaque/Acquire/Release/Volatile] methods.

Yes, exporting the primitive type polymorphism is too much, at least for now. (I know about the one public method that is still private.) The BT values can go private as well.

As you can see, I am experimenting with polymorphism of memory ordering, although I think we need to retain the Volatile versions of everything, which I find annoying. But the Plain Acquire Release and Opaque versions are just too niche-y; the power user that wants them needs to just use the new MO constants.

Regarding the final modifier, 1. it has no force since the class as a whole is already final, 2. it has been used inconsistently in the API to date, and 3. there is lots of review friction in this big changeset, which may require breaking it up into a queue of changesets. We’ll probably do that breakup when the time for integration comes closer.

The OP constants will stay public, to reduce the number of names while still providing full functionality. Also, RISC-V has min and max reduction ops (signed and unsigned) and that suggests to me that we are not done adding OP modes, for the get-and-operate API points.

Is the advantage of having these convenience methods enough to merit the 2x number of methods?

Which convenience methods would you remove? (What is the 2x?) Removing getLong(ref,long) is a big ask. I am deliberately making the getPrimitiveBits guys (the real new primitives) be private to Unsafe.

I have tried a few different experiments removing convenience methods. The system usually fought back, and in many cases I restored them. (E.g., I tried removing getLong(long) and had to back out; there seems to be too much JDK code using the no-reference versions, sadly.)

I would like to remove Unsafe API points, but the main thing I am attempting here is to simplify the interface between Unsafe and the underlying VM intrinsics scheme.

Would we risk running out of bits if we only use an 8-bit representation, considering potential new memory ordering types like "stable"? Would the performance not be the same if we use an int rather than a byte?

I don’t think we will run out of bits, even with bytes. We can widen to shorts or ints, but I think that is unlikely, even for the MO_XXX constants. (Famous last words; the internal accessDecorators are a beefy 64 bits. But they are far more than we want here.)

There are small benefits to using subwords (bytes or maybe shorts); the main one is that it is impossible to mix up the order of arguments, since you can only pass one of the MO or BT or OP constants to a byte. Byte is almost like boolean — nothing promotes to it, so if the static types line up, you are probably OK.

We could use ints, sure. But there are really not that many configuration choices here.

Because the interfaces are private to Unsafe, we can widen from byte if we need to do so.

(I had a wild idea, also, of packing the prefix bytes (intrinsic config) into a 64-bit long, along with the vmI::ID, and using that as a cookie for intrinsic lookup. But that seems to be unnecessary.)

It would also be possible to use an access scheme similar to the one in MemorySegment, where there is only one get method, but with different overrides for different layouts. Is this something worth exploring?

Yes, I think this is a possibility. My first cut here is to refactor the lower surface of Unsafe. (With some opportunistic simplifications to its upper surface.) But moving forward, the "primitive-bits" protocol could be shared with a few other clients. It’s even sharper-edged than getLong; you can crash real fast by passing a bad size-value to getPrimitiveBitsMO. But it might allow the MemorySegment to get simpler, in its lower surface that faces Unsafe. Same point for VarHandles.

Doing this will require making getPrimitiveBitsMO public in Unsafe. Some folks have already expressed discomfort with such a move, but I think we could come around to it. Maybe by making a pact that only a few classes will actually use that "maximally unsafe" API point.